Like many people, I ended up in information security management because I was leading the sysadmin / infrastructure / operations team at my workplace. A business requirement for IS compliance came up, and it landed on my plate, because compliance is assumed to be about configuring servers. As I got stuck in, I found that information security management requires an almost completely different worldview; this blog is my attempt to sum up some of the differences in perspective, in a very basic way.
Good Practice in Systems Administration
Most sysadmins in my experience aren't formally trained. Some may gain certification at some stage, but usually that's to prove what they already know - this is a theme which will come up again later. Most of us learned sysadmin at the server console, from IRC channels and web forums. Many of us had some kind of community around us, such as a local Linux User Group. We learned from our peers and taught ourselves.
One of the things that we picked up along the way is what's called "good practice". Some of us might even think we know "best practice". Most sysadmins will know not to expose unnecessary services to the Internet, to implement strong authentication where possible, to only give people the access they need to do their jobs, and so on. A competent sysadmin will deploy infrastructure that isn't obviously insecure or easy to exploit. A good sysadmin will even double-check their work.
This is a bottom-up approach of applying configuration options to protect infrastructure against threats for which there is a communal understanding. It's pretty good most of the time. Most infrastucture is, in practice, secure enough by following this approach.
From Bottom-Up to Top-Down
Information Security Management is, very basically, a way of answering the following Big Vague Question:
Is our stuff reasonably secure against plausible risks?
Your answer should show your working, so it can be inspected by other people both inside and outside your organisation. And by Future You, some time later, when circumstances have changed. All these vague words indicate things that can change over time.
There are three key weasel phrases in the question. First, "our stuff". What is it that your organisation cares about? What has value? This is the ISM definition of an asset, whether it's a physical server or a piece of information.
Secondly, "plausible risks". A risk is something which threatens an asset. A risk can affect the Confidentiality of the asset - giving access to unauthorised people. It can affect the Integrity - unauthorised changes. It can affect the Availability - the asset being there when people need it for legitimate purposes. This is known as "CIA", which has nothing directly to do with US intelligence agency.
What's plausible? It's easy to both come up with outlandish scenarios involving specially-trained squirrels in your datacentre HVAC, and to overlook basic risks like the people who have access across your office to water the plants. Risks are classified by their "likelihood", and by their "impact" or "severity" - what's the worst that happens if the risk transpires? The bigger the likelihood and the bigger the impact, the more you want to invest against the risk. Assessing the likelihood and severity of risks is one of the harder parts of information security management, and we'll talk about that more later.
Finally, "reasonably secure". What counts as "secure", and what counts as "reasonable"? It's very secure to shred all your paperwork and throw all your hard drives in a grinder. And on many a Monday morning before my first coffee, that can seem like a reasonable approach. But the impact on the normal function of your organisation would be significant. You want to plan how to control risks - typically to reduce their likelihood and severity. (The other ways to deal with a risk are to "avoid" it by not working in that area, "transfer" it by outsourcing or insurance, or just "accept" the risk if it costs more to control than it would impact the organisation.)
There isn't a single right answer to any of these weasel phrases, which is something which can infuriate people used to a world where things either work, or they don't. One of the hardest things for me to learn was when to say "this is appropriate to the situation", or "this is good enough".
The set of assets, risks and controls form the bulk of your Information Security Management System (ISMS). I went into this assuming it was some kind of software, but it can be anything, from a hand-written list to a spreadsheet to a version-controlled repository of data. Obviously some of these formats are easier to review and maintain than others!
Another Fine Mesh
It's worth noting here that the overarching question isn't directly answered by any particular bit of technical work that a sysadmin might carry out. Does this mean that the sysadmin's idea of "good practice" is meaningless? Of course not! But information security management is a top-down approach. It starts from the management question "what is of value to our organisation", then assesses the risks to those assets, then assesses what the organisation has done to protect against those risks. Everything we can do as a sysadmin to make data or systems more secure is a technical control. Other controls can involve changing policy and user awareness training.
The sysadmin good practice is operating in a vacuum. The job of information security management is to put the good work that's already been done, into the context of the organisation's assets and the identified risks. If you can understand both the top-down and bottom-up approaches and mesh them together, you have a huge advantage in information security management.
What Is Good Enough?
One phrasing I like is that it's easy for somebody to imagine the risks that they would present if they were trying to break into their own systems. To understand the risks that other people might present requires some understanding, and a little imagination. Some security standards might list specific threats you need to demonstrate protection against. If you can justify the budget, you can pay people with more experience to bring pretend risks against your organisation.
Just as many of us learned sysadmin through some form of community, it's valuable to participate in the infosec community. Find the places where people are talking about risks and controls, and think about whether they apply to your environment. A lot of this is done in the open, on blogs and LinkedIn, or at conferences. We talked earlier about assessing risk likelihood and impact, and how it's possibly the hardest part of information security management. Participating in the community is one of the best ways to help you make these assessments more accurately.
You don't have to be some kind of genius hacker to do information security management; I can understand the concept of SQL injection attacks without knowing how to run SQLmap. Similarly, you don't have to be an expert in implementing controls, provided you understand how they reduce your risks. Your job is to find, document and demonstrate the answers to the Big Vague Question, and that needs to be your focus.
One last thing on "good enough" - if your security measures are too cumbersome, they can prevent people getting their work done. This can lead to people trying to circumvent your security, which can introduce new risks. Try to understand what users are actually trying to get done and what they need to achieve that!
How Do We Know?
One last key thing seperates Information Security Management from sysadmin good practice. Usually as sysadmins we set stuff up in a way that's secure enough, then let it go. We rarely check log files unless things have gone wrong. When you have a set of controls in place to manage the risks to your assets, you need to review how effective they are. Again, the amount of effort you put into review depends on the likelihood and impact of the risk. This can cause a few "how do you prove a negative?" problems - an undetected hacker looks very much like a nonexistent hacker.
Your ISMS will also need reviews due to changes - in the organisation, in the world in general. Even if nothing major has happened in your business, you should be reviewing it at least annually. This is where "showing your working" comes into play. If you've documented why you decided something, it's much easier to review whether your reasoning is still valid, rather than trying to second guess yourself!
Summary
This is a very brief overview, but I think it contains the key concepts I wish somebody had explained to me, when I was first handed information security responsibilities as a sysadmin. I hope you find it useful!